home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / sdr / sdr-charter.txt < prev    next >
Encoding:
Text File  |  1993-04-07  |  4.5 KB  |  110 lines
  1. Source Demand Routing (sdr)
  2.  
  3. Charter 
  4.  
  5. Chair(s):
  6.      Deborah Estrin  <estrin@isi.edu>
  7.      Tony Li  <tli@cisco.com>
  8.  
  9. Routing Area Director(s) 
  10.      Bob Hinden  <hinden@eng.sun.com>
  11.  
  12. Mailing lists: 
  13.      General Discussion:sdrp@caldera.usc.edu
  14.      To Subscribe:      sdrp-request@caldera.usc.edu
  15.      Archive:           jerico.usc.edu:~/pub/sdrp
  16.  
  17. Description of Working Group:
  18.  
  19. The SDR Working Group is chartered to specify and promote the use of
  20. SDR (Source Demand Routing Protocol) as an interdomain routing protocol
  21. capability in conjunction with IDRP and BGP interdomain routing
  22. protocols.  The purpose of SDR is to support source-initiated selection
  23. of interdomain routes, to complement the intermediate node selection
  24. provided by BGP/IDRP.
  25.  
  26. The goal of the SDR working group is to release the components of SDR
  27. as IETF Prototypes and to obtain operational experience with SDR in the
  28. Internet.  Once there is enough experience with SDR the working group
  29. will submit the SDR components to the IESG for standardization.
  30.  
  31. SDR has four components: Packet formats for protocol control messages
  32. and encapsulation of user datagrams, Processing and forwarding of user
  33. data and control messages, Routing information distribution/collection
  34. and route computation, Configuration and usage.
  35.  
  36.  
  37. Our strategy is to:
  38.  
  39. 1. Define the format, processing and forwarding of user datagram and
  40. control messages so that SDR can be used very early on as an efficient
  41. means of supporting "configured" inter-domain routes.  User packets are
  42. encapsulated along with the source route and forwarded along the
  43. "configured" route.  Routes are static at the inter-domain level, but
  44. are not static in terms of the intra-domain paths that packets will
  45. take between specified points in the SDR route. The impact of
  46. encapsulation on MTU, ICMP, performance, etc., are among the issues
  47. that must be evaluated before deployment.
  48.  
  49. 2. Develop simple schemes for a) collecting dynamic domain-level
  50. connectivity information, and b) route construction based on this
  51. information, so that those domains that want to can make use of a
  52. richer, and dynamic set of SDR routes.
  53.  
  54. 3. In parallel with 1 and 2, develop usage and configuration documents
  55. and prototypes that demonstrate the utility of static-SDR and
  56. simple-dynamic-SDR.
  57.  
  58. 4. After gaining some experience with the simple schemes for
  59. distribution, develop a second generation of information distribution
  60. and route construction schemes.  We hope to benefit from discussions
  61. with IDPR and NIMROD developers at this future stage because the issues
  62. faced are similar.
  63.  
  64. 5. We will also investigate the addition of security options into the
  65. SDRP forwarding and packet format specifications.
  66.  
  67. Goals and Milestones: 
  68.  
  69.    Mar 93 Post an Internet Draft of packet forwarding and control message 
  70.           format and protocol for IP.                                          
  71.  
  72.    Jun 93 Post as an Internet Draft the SDR MIB.                               
  73.  
  74.    Jun 93 Post as an Internet Draft the SDR Usage and Configuration document. 
  75.           This is the highest priority after the draft spec in order to 
  76.           demonstrate how even static-SDR can be used to achieve concrete 
  77.           objectives.                                                          
  78.  
  79.    Sep 93 Post as an Internet Draft the BGP/IDRP Extensions Specification. As 
  80.           mentioned in the Internet Draft there are a few extensions to 
  81.           BGP/IDRP needed to support SDR. These must be detailed and 
  82.           documented.                                                          
  83.  
  84.    Sep 93 Submit as an Internet Draft a specification for Route Setup.         
  85.  
  86.    Nov 93 Post as an Internet Draft a SDR Deployment Plan.                     
  87.  
  88.    Dec 93 Post as an Internet Draft a document describing the 
  89.           distribution/acquisition of Information to construct richer SDR 
  90.           routes.  The initial versions of SDR will use only configured 
  91.           information (some of which may be derived from BGP/IDRP) as the basis
  92.           for constructing source routes.                                      
  93.  
  94.    Dec 93 Post as an Internet Draft a specification for SDR Multicast.         
  95.  
  96.    Mar 94 Submit the set of SDR specifiations to the IESG for consideration as 
  97.           a Proposed Standard.                                                 
  98.  
  99.    Mar 94 Submit the set of SDR specifications to the IESG for consideration as
  100.           a Prototype protocol.                                                
  101.  
  102.  
  103. Internet Drafts:
  104.  
  105.   No Current Internet drafts.
  106.  
  107. Request For Comments:
  108.  
  109.   None to date.
  110.